home *** CD-ROM | disk | FTP | other *** search
/ CU Amiga Super CD-ROM 2 / CU Amiga Magazine's Super CD-ROM 02 (1996)(EMAP Images)(GB)[!][issue 1996-04].iso / magazine / amiga_e / amigae.june.archive / 000030_crash!minyos.xx….OZ.AU!s924723_Tue, 8 Jun 93 19:48:48 PST.msg < prev    next >
Text File  |  1993-08-31  |  3KB  |  66 lines

  1. Received: by bkhouse.cts.com (V1.16/Amiga)
  2.     id AA00000; Tue, 8 Jun 93 19:48:48 PST
  3. Received: from peladon.rmit.OZ.AU by crash.cts.com with smtp
  4.     (Smail3.1.28.1 #15) id m0o3FRO-0002aQC; Tue, 8 Jun 93 18:59 PDT
  5. Received: from minyos.xx.rmit.OZ.AU by peladon.rmit.OZ.AU with SMTP id AA06087
  6.   (5.65c/IDA-1.4.4 for <amigae@bkhouse.cts.com>); Wed, 9 Jun 1993 11:57:00 +1000
  7. Received: by minyos.xx.rmit.oz.au
  8. Message-Id: <9306090156.4096@minyos.xx.rmit.oz.au>
  9. Date: Wed, 9 Jun 1993 11:56:37 +1000 (EST)
  10. In-Reply-To: <m0o342T-0000kOC@crash.cts.com> from "Barry D. Wills" at Jun 8, 93 08:44:00 am
  11. X-Mailer: ELM [version 2.4 PL21]
  12. Mime-Version: 1.0
  13. Content-Type: text/plain; charset=US-ASCII
  14. Content-Transfer-Encoding: 7bit
  15. Content-Length: 2211
  16. From: s924723@minyos.xx.rmit.OZ.AU (Son Huu Le)
  17. To: BWILLS@kirk.safb.af.mil (Barry D. Wills)
  18. Cc: amigae@bkhouse.cts.com
  19. Subject: Re: [untitled reply]
  20.  
  21. > >Read() is just slightly slower than Fgets() (;
  22. > I'll  use it.  When I get 2.1 I can start supporting both OSs.  'til then you 
  23. > should have little trouble plugging in the read() function from V0.10b and 
  24. > replacing Read() with Fgets().  BTW, why the difference in speed?  This could 
  25. > be crucial since I'm basically reading into a buffer and copying part of the 
  26. > buffer to a string variable.  That extra step takes some time.
  27.  
  28. Actually, after examining epp013b and doing a bit more testing, I must say that
  29. your method is almost(!?) as fast as Fgets() _if_ you increase the buffer et al
  30. to max.. Then epp013b is slower by about half a second, processing epp.e.
  31. Must be the extra passing and parsing. Also, since E doesn't registerise
  32. procedure variables, sometimes it's slower (although still smaller) than
  33. optimised C code. For max speed, use assembly..
  34.  
  35. > Thanks for the info. I hope that's fixed in V0.13b.  I'll take another look at
  36. > it.  |-)
  37.  
  38. Yep, it's fixed. Btw: can you change your parsing routine to accept main() and
  39. not "main ()".. it's looks wrong. (;
  40.  
  41. > I can sympathize.  What kind of system are you running?  I'm using a
  42. > Deringer-030, 25MHz w/32-bit RAM, and it breezes through most things, but when
  43. > I stepped down to test EPP on the 68000 it was physically distressing! 
  44.  
  45. Amiga 2000 with 105 meg GVP series II - plain 68000. Now you know how I feel! 
  46.  
  47. > Realistically, Son Le, I don't know of a compiler/linker out there that's
  48. > faster than EC (my hat off to Wouter!).  It would definitely be faster if an
  49. > entire source file is read in at once instead of just a piece at a time. And I
  50. > have the memory for it, but most Amiga owners don't.  To compromise I added a
  51. > command-line switch in EPP V0.13b to specify input buffer size. If you got it,
  52. > use it.  |-)
  53.  
  54. I don't know, but I feel the line parsing is what's slowing it down. Maybe I'll
  55. have a closer look at your code and see if I can speed it up. I'll keep you
  56. posted.
  57.  
  58. On the subject of your sources (or anyone's for that matter) post them!
  59. The more sources, the merrier and the more we can learn!
  60.  
  61. (To Norman Kraft, sorry Barry, how do we post sources? UUencode or plain text?
  62. Source line/length limit?)
  63.  
  64. Son Le